The embodiments disclosed within this specification relate to runtime analysis of application program code. More particularly, the embodiments relate to detecting memory leaks in an application.
A memory leak is a particular type of memory consumption by an application where the application is unable to appropriately release system memory it has acquired. A memory leak can diminish the performance of the system on which the application is instantiated by reducing the amount of available memory. If too much of the allocated memory remains un-released, the amount of available memory will be excessively depleted, and all or part of the system typically will cease to function properly. For example, the application may fail or the system may slow down unacceptably due to thrashing, which is a degenerate situation on the system where increasing resources are used to do a decreasing amount of work. A software application that leaks memory excessively can run out of available virtual memory and can, as a result, cease to function, which is commonly known as a crash.
Techniques such as garbage collection are sometimes used in an attempt to reclaim memory from application data objects that are no longer in use. Garbage collection works effectively only in certain environments such those that are available for Java and managed code. Garbage collection is not very efficacious for native code (ie. C/C++) programs. The difference is that Java/managed code treats all object references dynamically such that the objects are relocatable when a garbage collection occurs. The garbage collector recognizes all references as such, and can clean up any objects whose reference count has dropped to zero. Native code programs use actual data pointers that do not change while the program is running; the objects referenced by these static pointers are not reference counted and thus can be leaked if the situation arises where no pointers reference them.